The following relates to machine control planning. In particular, it is directed towards exception handling. More particularly, it is directed towards exceptions handling using flexible planning based at least in part user preferences.
Model-based planning is used for creating machine control plans. It is based on a notion that each component of the system can send a model of its behavior to a central planner or controller. The controller interprets the models to determine the capabilities and constraints of the system components. Subsequently, upon receiving one or more jobs to process, the controller generates a plan to process the one or more jobs based on the components' capabilities and capability constraints described within each of the component models. The plan may then be confirmed by each component of the system to ensure that each component can execute its portion of the plan. With model-based planning, plans are often built based on the assumption that all components will work as expected. Thus, model-based planning is often used to create plans only for normal behavior and is not involved in recovering from failures or exceptions (e.g., associated with one or more malfunctioning components/modules of a system, etc.) in the execution of these plans. Unfortunately, this assumption is often erroneous.
In one instance, conventional systems handle such exceptions associated with such plans by bringing the machine, apparatus, process, etc. to a safe state (e.g., stop, idled, off, etc.) and then trying to recover from the safe state. With some high-speed systems, gracefully halting a running system may be difficult or even impossible. In addition, frequent halting the system for error recovery (e.g., with every component failure) may lead a user to believe that the system is unreliable or defective. In another instance, a set of pre-defined rules are used to determine an alternative plan, for example, without invoking the planner. However, creating a set of rules for all possible exceptions may be time-consuming, error-prone, and/or not possible. Moreover, with systems in which the configuration is only known at boot-up and can be updated on-line, a set of pre-defined rules may become invalid or lead to inefficient handling of exceptions.
It may be possible to recover from an exception without operator intervention by using simple recovery procedures such as purging jobs, restarting the system, employing pre-determined rules, etc., and then completing the uncompleted portions of the current job. This approach may be unsatisfactory for systems with parallel modules or a potentially large number of work units in process. With different parts of a job distributed among multiple modules, these simple procedures may lead to time delays, lost processing time, inconsistencies in the system state, lost costly materials (purged jobs), and/or unexpected component/module interactions.